I believe we need the MSBuild option from day 1 or some alternative.

dotnet build --runtime ... MyRepo.sln fails today with error NETSDK1134: Building a solution with a specific RuntimeIdentifier is not supported. If you would like to publish for a single RID, specifiy the RID at the individual project level instead. and so you cannot actually decide to build an entire solution for a given RID. Doing this per project is slow and unmaintainable for larger projects.

Interesting. I didn't know that. I didn't include .sln files in my experiments/research. Fail on that.

I take it that you'd be fine with -r any as long as it is respected on a .sln file. Yes?

9a95282

I take it that you'd be fine with -r any as long as it is respected on a .sln file. Yes?

Yes, provided you can build the entire solution as desired with a single command, I think that "fits the bill".

However, it's generally nice to be able to do just dotnet build or just dotnet run and have things work as expected and not have to pass command line args for it to be "correct" (assuming the project wants portable by default).

Just as an FYI, NuGet has some issues today with RID specific assets: NuGet/Home#10571

Ideally these would get fixed as part of this to ensure that pulling in native dependencies "just works".

Yup. We need a followon spec that improves building and consuming RID-specific packages. So many problems. @terrajobst has tried to resolve this in the past. I'd like us to take another run at it for .NET 7.

How much thought has been put forward on linux-x64? Unlike Windows, there can be a lot of differences between the various distros and writing a portable Linux app can be difficult.

In some cases, you might have different native dependencies for Ubuntu vs RHEL vs SLES vs etc (and sometimes even different dependencies between each of these due to differences in what ships in the system by default).

Very little thought. I'd heard very few requests for build-time differentiation. We are forced to do it for Alpine (musl libc), but that's logically separate from what you are getting at. Certainly, we could extend the RID graph for distros. We need compelling scenarios.

One scenario that comes to my mind is dealing with openssl since there can be different incompatible versions/variants between distros and versions of the same distro.

We already have that problem solved. Put another way, I don't think enable linux as any any-style RID would change our approach to OpenSSL. Same with ICU. Perhaps I'm missing something.

We have solved it for the .NET Runtime dependencies on icu and openssl by using non-standard mechanisms to bind to these libraries. The solution was non-trivial to setup and requires constant maintenance. (In theory, we could have used similar non-standard mechanism to bridge the glibc/musl differences too, but that was too complex even for our taste, so we choose to let glibc/musl bleed out in the UX.)

We have not solved it for 3rd party packages with native libraries that depend on openssl, icu and other native libraries. For example, the dependency on libtinfo was giving me a hard time in one of my projects. I think it is rare for authors of 3rd party packages with native dependencies to go through the pains of targeting generic linux RID. The authors of 3rd party packages with native dependencies typically end up picking up a set of Linux distros, configurations and architectures to build and package the native dependencies for. If your project target platform is lucky to be on this list, great! If it is not, you are on a unhappy path.

The only scalable way to solve this is to add fallback to build-from-source for the native dependencies (#233 (comment)). Fallback to build-from-source would work well for current-RID-specific publish, so this proposal is good for it. It would not work well (without additional manual configuration) for RID-neutral publish.

I don't think this is true (e.g. Client Blazor) and in .NET7 e.g. MAUI

It's not true for mobile SDKs (iOS, tvOS, etc), where only the third build type is valid.

Totally true. My thinking is that these app types already have bespoke build experiences so many of these default experiences don't apply. Fair?

The reason to keep portable apps as the default is that it is easier for non-container web developers that target a different operating system than the one they use locally for development.

Do we have any evidence that this workflow is used by developers?

I don't, but I expect it happens a lot. For example, anyone who publishes directly from Visual Studio to a cloud may benefit from this. That said, I'm not arguing this point just conceding that this could be a legit reason.

Is the intention to change every existing template? In other words will unit test project not produce RID specific framework model?

This isn't a template change. I don't think unit tests care one way or the other. Unless I'm missing something, I'd expect them to be the least impacted.

How is this going to work on configurations where SDK is built for the more generic RID than I'm on (e.g. some Linux flavours) ?

edited: I wanted to post in a new conversation, but clicking the blue + on the same line number, GitHub's forcing me to add a comment to this thread :( I'll repost on a different line.

For the most part, we don't offer RIDs for different Linux distros (AFAIK). The key outlier is Alpine. Outside of Alpine, I don't see that mattering. Today, the product only cares about glibc and musl c.

It's not true for mobile SDKs (iOS, tvOS, etc), where only the third build type is valid.

For platforms that only support self-contained apps (or vice versa if that exists), it seems redundant to have to specify it.

It does. Someone has to win ;)

More seriously, -r is an equally legit option for framework dependent apps and self-contained ones. IMO, it is incoherent to change the deployment mode as a result of specifying a RID.

Please also consider how NuGet lock files should work. Today, the following commands result in an error: NuGet/Home#9195

dotnet new console
dotnet restore --use-lock-file
dotnet restore --locked-mode -r linux-x64

While that looks like a contrived example (why would someone restore locked mode for a specific RID?), consider that customers want to use locked mode on CI build pipelines (via Directory.Build.props or environment variable), and that dotnet publish -r linux-x64 does an implicit restore. Bang, restore failed, so publishing failed, and CI failed.

Customers want to use lock files and locked mode so they can use floating versions, but still get consistent restores across all machines, and also some package substitution prevention, as lock files ensure the package's content hash is the same when packages are extracted.

There needs to be a way for the SDK to ensure that the set of packages NuGet is asked to restore (plus the set of RIDs that NuGet is informed about) is consistent, regardless of what RID is being built/published by the comment line arguments.

This spec seems to be a higher level than these details, but lock files need to be designed to be workable from the top. NuGet can't have a workable lock file experience when the SDK reports a different set of packages on different actions.

This is a good issue. I hadn't thought about that. Fortunately, this change doesn't come until .NET 7 so we'll have time properly design this experience. I agree with you.

Many users (likely most) do not want that.

Is this actually true? Do we have evidence on the claim?

Maybe I'm too close to the implementation (and probably not our target customer), but I use self-contained apps much more than targeting a specific RID with a framework-dependent app. I've honestly never actually published an app -r XXX --self-contained false outside of testing the feature.

Totally agree. I think most people don't (A) realize that this model even exists, (B) don't realize why they would use it, and (C) don't understand the syntax. My take is that RID specific fx-dependent apps are the best default for the product. That's much of the thesis of this proposal.

I wonder if we can get some data around which deployments are used more often.

I would hope that the more used scenarios would be easier for the user - less settings to pass to the command line / set in the .csproj.

I think getting deployments for real world desktop apps is also important.

What you want for a simple command line tool and what you want for a game or a more advanced app might be very different. I'm not sure how well this model fits for Paint.NET for example where, from what I've seen from Rick Brew in the C# Community Discord, it seems to be a bit of a different setup and deployment model.

It would be very hard to reason about usage patterns/data and I don't think it was lead us to the right decision, in part due to what @tannergooding raises.

The current system doesn't align well with user needs. I don't think most users want portable by default and the focus on -r is not good UX. Instead, users can focus on --self-contained and specialize it with a architecture/OS info as an option. I don't see data pointing us in that direction given how challenging the current UX is.

-- For reference, the above is also not be speaking abstractly. I maintain several OSS libraries and tools independently of work and these are the kinds of problems I actively run into already.

I'd ideally be able to produce small portable deployments that the I can then finish doing things like AOT or R2R on at install time or first launch so that startup is fast

This is separate from the overall conversation, but we don't intend to build those experiences. We're focused on dev-time crossgen and awesome JIT features w/nothing in-between. Today, crossgen has a couple characteristics that we really like:

• The build produces final optimized artifacts, per OS/arch.
• Those artifacts can be signed.

The NGEN experience had neither of those characteristics and had a ton of UX problems. We're not going to recreate those challenges.

I honestly can't think of a time when I've wanted a fx-dependent app. So I want to verify that most users do want that behavior.

The thinking behind this change is super simple (as I articulate in the doc):

• fx dependent is the default build type, since .NET Core 1.0.
• rid-specific is relevant to fx-dependent apps, using an implicit RID, and this will be the default in .NET 7.
• specifying an explicit rid shouldn't change the deployment type.

I respect and sympathize with the point you are raising. It's legit. My view is coming from a very different direction, as I've articulated. I am a fan of self-contained. Judging by our container image pulls (10s of millions/month), self-contained is not the primary developer scenario.

I think the new model is generally better. It's not better for all cases but that's typical of change.

Also, for the x64 emulation scenario, rid-specific targeting absolutely benefits from self-contained not being the default.

This is separate from the overall conversation, but we don't intend to build those experiences.

I think that's unfortunate and is overlooking the independent developer scenario. In particular certain things like signing simply aren't a consideration for many independent developers. Authenticode certs tend to start at $500-600/yr and that's out of reach for a lot of projects (assuming they aren't in the .NET Foundation or similar). Having the ability to easily perform steps at any stage, including post-install, is general goodness IMO and allows developers to setup their CI flow however works best for them, even if they are signing, etc.

Sure. I'd rather us focus on dynamic PGO than a post-install NGEN replacement. BTW: I don't think that NGEN was very popular either, particularly among the audience you are describing.

I think that might have been for other reasons and that dynamic PGO isn't really a viable alternative for handling fast startup, its more about tuning the running application to achieve higher end throughput.

I think its worth considering what would be required to make our core build tools, including crossgen, the linker/trimmer, and others usable either standalone or as part of the SDK. I imagine its not much and that its mostly just packaging them as dotnet tools. This would cover the normal "publish" scenario, running them as post-build or independent CI steps, or even integration into custom build pipelines (which frameworks like Unity have).

Since --self-contained is kind of a lot to type. What do you think about adding a short option -s for this switch?

dotnet publish -r linux-x64 -s

Yup. Fan of that (or something like it).

If/when we do that, I'd suggest that we enable an implicit RID by default. That would enable this scenario:

PS C:\Users\rich\app> dotnet publish --self-contained
Microsoft (R) Build Engine version 16.8.3+39993bd9d for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
  Restored C:\Users\rich\app\app.csproj (in 61 ms).
C:\Program Files\dotnet\sdk\5.0.103\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.RuntimeIdentifierInference.targets(136,5): error NETSDK1031: It is not supported to build or publish a self-contained application without specifying a RuntimeIdentifier. You must either specify a RuntimeIdentifier or set SelfContained to false. [C:\Users\rich\app\app.csproj]

I would have the RID default to the host OS's platform and architecture.

Filed an issue on this. dotnet/sdk#19576

Perfect! Thanks.